1. Technical Field
This following relates to vehicle-diagnostic systems. More particularly, the following relates to an apparatus, system and method for obtaining information for analyzing vehicle data.
2. Description of Related Art
About thirty five or so years ago, transportation vehicle manufacturers instituted on-board vehicle diagnostics (“OBD”) systems to assist in diagnosing failures of control and monitoring systems of the vehicles manufactured by them. To do this, the OBD systems typically generate vehicle data that can be used to carry out the diagnostics of the command,-control and monitoring systems of the vehicle (hereinafter referred to as “vehicle systems”). The OBD systems are generally integrated into, integral to or otherwise combined with the vehicle systems that the OBD systems are intended to diagnose. The OBD systems, however, may be deployed separate from any of the vehicle systems.
While the earliest OBD systems did not conform to any standard protocol and varied greatly from one vehicle manufacturer to another, some (and later most) North American vehicle manufacturers in the mid-1980's adopted a standard protocol for OBD, namely OBD-I. For a myriad of reasons, including, for example, being able to provide additional monitoring and reporting services, many vehicle manufacturers adopted a second generation of the OBD protocol, namely OBD-II, for diagnosing failures of the vehicle systems.
Like its predecessors, the OBD-II protocol specifies various parameters of vehicle operation, such as vehicle emissions, that are to be available for diagnostics, and command-and-control purposes. The OBD-II protocol also provides standardized rules for monitoring and reporting malfunctions with vehicle operation. For example, when a malfunction is detected by an OBD system that complies with OBD-II, then the OBD system may alert the vehicle systems by providing vehicle data that includes an indication of the malfunction. The indication may then be used by the vehicle systems for reporting the malfunction. The reporting the malfunction may be carried out in a number of ways, including for example, illuminating a malfunction-indicator lamp (MIL), which is sometimes embodied as the well known “Check Engine” light.
In addition, the OBD-II protocol, like its predecessor, also provides that diagnostic-error codes and other vehicle data (hereinafter collectively referred to as “vehicle data”) are to be stored for a period of time. This way, a vehicle-maintenance technician, other person and/or machine (collectively referred hereinafter to as “user”) can access the vehicle data at a later time to assist in diagnosing the cause of the malfunction, even if the malfunction is no longer occurring.
To facilitate such diagnostics, monitoring, reporting and storage of vehicle data, the OBD system typically includes a device, commonly referred to as an “OBD” device, for obtaining, storing and/or analyzing the vehicle data. The OBD device, which may be embodied a combination of hardware, software, and/or firmware, and may be a stand-alone device (or number of devices). Alternatively, the OBD device may be integrated into, integral to or otherwise combined with the portions of the vehicle systems.
In either case, the OBD device may be adapted to (i) communicate with the vehicle systems to retrieve or otherwise obtain vehicle data generated by the OBD, and (ii) communicate the retrieved vehicle data to user of the OBD system. Using a diagnosis and command-and-control (DCC) device, which is capable of interfacing with the OBD device, a user may tap into the valuable resource of information provided by the OBD system.
For example, the OBD device may be adapted to monitor vehicle data generated by the OBD system for errors that occur during normal operation of the vehicle. And if such errors occur, then the OBD device may record and/or report the vehicle data to the user. The vehicle data can be later downloaded to or otherwise obtained by the DCC device when, for example, the vehicle is serviced or otherwise queried. After receipt, the vehicle data may then be presented to the user in an appropriate fashion via a user interface of the DCC device. The user interface may present the vehicle data in any number of ways, including for example, a format in accordance with the OBD-I and/or OBD-II protocols.
At present, there are many known DCC devices that are able to tap into the valuable resource of information provided by the OBD system. These DCC devices can vary from very simple to extremely sophisticated computing devices, some of which commonly called scan or diagnostic tools. Included among the more sophisticated DCC devices are the Modular Diagnostic Information System (“MODIS™”) and the diagnostic scanner controller system MT2500™, both of which are manufactured and licensed for use by the present assignee. Details of exemplary DDC devices may be found in (i) U.S. Pat. Nos. 6,892,216; 6,845,307; 6,714,846; 6,693,367; 6,615,120; 6,564,128; 6,560,516; 6,512,968; 6,477,478; 6,141,608; and 6,029,508; and (ii) U.S. Patent Application Publication Nos. US20050096805; US20050075768A1; US20050085963; US20050027403A1; US20040172177A1; US20040003050A1; and US20030020759A1; all of which are assigned to the present assignee (or subsidiary thereof) of the present and incorporated herein by reference.
In addition to its processing abilities, each of many DCC devices employs logic and content, such as parametric and/or characteristic data, for analyzing the vehicle data received from the OBD system. This way, when a user attempts to analyze a condition of the vehicle, the DCC device may (i) obtain vehicle data, such as a diagnostic-error code, from the OBD system, and then (ii) process the diagnostic-error code as a function of the content so as to provide to the user an analysis of the condition of the vehicle. Accordingly, each of the DCC devices can dramatically reduce the time for servicing and/or making of reparations to the vehicle, thereby, reducing the labor-repair costs and increasing vehicle owner satisfaction and convenience.
Since the introduction of OBD systems, vehicles and their corresponding onboard-vehicle systems have increasingly become, and if history serves as an indicator the future, will continue to become substantially more complex; adding more components and functions carried out thereby. This growing complexity of the vehicles and their corresponding vehicle systems increasingly compounds a likelihood of malfunction of such vehicles and vehicle systems. This is because the probability of failure of the components, functions and interactions therebetween necessarily increases as a function of the increase in the number of such components, functions and interactions. Accordingly, DCC devices are presently and will continue to be indispensable in the practice of vehicle maintenance and repairs.
Nonetheless, economic infeasibility and computing platform restrictions generally prevents every one (if not any one) of the aforementioned DCC devices from containing all of the logic and/or content (collectively referred to hereinafter as “information”) for analyzing the vehicle data for every vehicle that uses an OBD system. This is because the information for analyzing vehicle data is often sold by vehicle make, make and/or model year, and purchasing all the information for all (or even a significant subset of) possible vehicle makes and models is generally cost prohibitive.
In addition, even if a DCC device possesses all available information for analyzing vehicle data for a given vehicle or set of vehicles at a given point in time, the DCC device may not possess information for analyzing the vehicle data that was released after that point in time. This not so infrequent situation can happen when, for example, the OBD device or its firmware version was not available or was updated after the given point in time. The same situation may occur when as noted, the information possessed by the DCC device does not include information for analyzing the vehicle data of a particular (e.g., a new) model year of the given vehicle or set of vehicles.
Moreover, some of the DCC devices do not possess the ability to store on board in non-volatile form any of the information for analyzing the vehicle data. Thus, such information has to be loaded into each of these diagnostic tools each time the tool is to be used. To load the information, many of these diagnostic tools use a removably-insertable cartridge or other memory module that is programmatically configured with the information. And for the same reasons as above, the cartridge or other memory module may not be programmatically configured with the information for analyzing the vehicle data of the given vehicle or set of vehicles.
As can be readily discerned from the foregoing, when the DCC device lacks information for analyzing vehicle data for a particular condition, the tool becomes useless for carrying out any part of the analysis and/or repair of a vehicle until the tool obtains the lacking information. Obtaining the lacking information, however, has been a time-consuming and arduous undertaking. For example, obtaining the lacking information may take days or even weeks given that the time between placing an order for and delivery of the lacking information may be days or even weeks. Moreover, many times a trained, programming specialist is required to install the lacking information, and such trained, programming specialist may not be readily available.
The task of obtaining the lacking information for the DCC device becomes more problematic when considering that manufacturers of DCC devices have an economical interest in ensuring a profit on providing the information for analyzing vehicle data. To ensure profitability, many of the DCC devices are designed and programmed according to one or more proprietary formats, which thereby limits the sources from which the lacking information may be purchased and/or obtained. In addition, as noted above, the information for analyzing vehicle data is often sold by vehicle make, model and/or model year, and is generally available as an all or nothing proposition, and not on a piecemeal basis.
Thus, when a DCC device obtains specific set, particular part or otherwise select vehicle data associated with an operation of the vehicle (collectively referred to hereinafter as “select vehicle data”), and then ascertains that it lacks information for analyzing the select vehicle data, not only does the DCC device become useless for analyzing and repairing the vehicle, but also, the owner of the DCC device is saddled with potentially paying for more information than needed to analyze the select vehicle data.
Therefore, what is needed is an apparatus and/or system that includes a computing platform that is operable to obtain, in a timely fashion, at least the information for analyzing the select vehicle data, whereby after obtaining this information, the computing platform is not rendered useless for carrying out an analysis and/or repair of a vehicle. Such an apparatus and/or system may be advantageously configured to obtain the information for analyzing the select vehicle data without the need for purchasing all (or even a significant subset) of the information for all vehicles, and without aforementioned problems related to obtaining such information. However, such an apparatus and/or system may benefit equally as well when configured to obtain the information for analyzing the select vehicle data that is sold by vehicle make, model, model year, or some combination thereof.
Additionally, there is a need for a method directed to obtaining, in a timely fashion, at least the information for analyzing the select vehicle data, whereby after obtaining this information, an analysis and/or repair of a vehicle ay be carried out. This method may advantageously obtain the information for analyzing the select vehicle data without the need for purchasing all (or even a significant subset) of the information for all vehicles, and without aforementioned problems related to obtaining such information. Such method may also advantageously obtain the information for analyzing the select vehicle data that is sold by vehicle make, model, model year, or some combination thereof.